Automated allocation of resources to functional areas of an enterprise activity environment

ABSTRACT

A computer implemented method, system and/or computer program product automatically allocates resources to functional areas of an enterprise activity environment. A skill level of a resource is determined for multiple functional areas. An affinity index is created and associated with each of the multiple functional areas, wherein the affinity index is based on a level of productivity drop of other resources in a specific functional area if the resource is assigned to another functional area. Expected resource and skill level requirements of a project are identified. The resource is automatically allocated to one or more functional areas based on the affinity index associated with a particular functional area in view of the expected resource and skill level requirements.

The present application is a continuation of U.S. patent applicationSer. No. 12/868,049 (Atty. Docket No. END920100092US1), filed on Aug.25, 2010, and entitled, “Automated Allocation of Resources to FunctionalAreas of an Enterprise Activity Environment,” which is incorporatedherein by reference.

BACKGROUND

The present disclosure relates to the field of computers, andspecifically to the use of computers in allocating resources. Still moreparticularly, the present disclosure relates to the use of computers toallocate resources to functional areas of an activity environment.

SUMMARY

A computer implemented method, system and/or computer program productautomatically allocates resources to functional areas of an enterpriseactivity environment. A skill level of a resource is determined formultiple functional areas. An affinity index is created and associatedwith each of the multiple functional areas, wherein the affinity indexis based on a level of productivity drop of other resources in aspecific functional area if the resource is assigned to anotherfunctional area. Expected resource and skill level requirements of aproject are identified. The resource is automatically allocated to oneor more functional areas based on the affinity index associated with aparticular functional area in view of the expected resource and skilllevel requirements.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is an overview of a software factory that may be used in oneembodiment of the present disclosure;

FIG. 2 is a flow-chart of steps taken to create custom software throughthe use of work packets in a software factory;

FIG. 3 presents an overview of the life cycle of work packets;

FIG. 4 presents an overview of an environment in which work packets aredefined and assembled;

FIG. 5 is a high-level flow-chart of steps taken to define and assemblework packets;

FIG. 6 illustrates an exemplary computer in which the present inventionmay be utilized;

FIG. 7 depicts resources being allocated/reallocated to differentactivities areas within a software factory; and

FIG. 8 is a high-level flow chart of one or more steps executed by aprocessor to allocate resources to one or more functional areas of anenterprise activity environment.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art, some or all of thepresent disclosure may be embodied as a system, method or computerprogram product. Accordingly, the present disclosure may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, some or all of the features described in the presentdisclosure may take the form of a computer program product embodied inone or more computer-readable medium(s) having computer-readable programcode embodied thereon.

Any combination of one or more computer-readable medium(s) may beutilized. The computer-readable medium may be a computer-readable signalmedium or a computer-readable storage medium. A computer-readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer-readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer-readable storagemedium may be any tangible medium that can contain or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer-readable signal medium may include a propagated data signalwith computer-readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer-readable signal medium may be any computer-readable medium thatis not a computer-readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer-readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

As described herein, one embodiment of the present disclosure relates tocapacity planning and resource management, and more particularly to amethod for generating an automated optimal scheduling under requirementsof existence of sticky functional area skills and necessity of differenttreatment for highly productive resources.

Capacity planning and resource management simultaneously automate andoptimize various aspects of service offerings. One problem associatedwith dynamic capacity planning can be formulated using Equation (1):

$\begin{matrix}{{x(t)}^{*} = {\underset{{c_{i}{({x{(t_{j})}})}} \geq 0}{argmin}{f\left( {{x\left( {t - 1} \right)},{\ldots \mspace{14mu} {x(0)}}} \right)}}} & {{Equation}\mspace{14mu} (1)}\end{matrix}$

where x is the decision vector, t is time, f is the objective andc_(i)(x(t_(j)) are the i^(th) constraints at time j.

The present disclosure utilizes a reformulation of Equation (1) (shownbelow as Equation (2)) in such a way that it is both a “fair”representative of the problem (of optimizing capacity planning) and“straight-forward” to solve.

In one embodiment of the present disclosure, a software factory isutilized as an enterprise activity environment in which resources are tobe allocated in accordance with parameters described herein. A softwarefactory establishes a disciplined approach to leveraging globalresources for application development and maintenance activities. Asdescribed herein, resources with similar skills are pooled by functionalarea(s) and geographically organized into assembly centers. Resources inan assembly center may have skills that enable them to work in otherfunctional areas/move to other assembly centers. A resource allocated tomultiple functional areas has a primary functional area. In the presentdisclosure, attention is paid to managing the allocation of resources toprimary functional areas by taking into account both short term and longterm consequences.

Described herein is a software factory, which includes a collection ofbusiness and Information Technology (IT) governance models, operationalmodels, delivery methods, metrics, environment and tools bundledtogether to improve the quality of delivered software systems, controlcost overruns, and effect timely delivery of such systems. The softwarefactory described herein offers a practical solution to developingsoftware systems using multiple sites that are geographicallydistributed. The issues of varying time zones and the hand-over betweenvarious teams residing in such time zones are handled by exchanging workpackets. A work packet is a self-contained work unit that is composed ofprocesses, roles, activities, applications and the necessary inputparameters that allow a team to conduct a development activity in aformalized manner with visibility to progress of their effort affordedto requesting teams.

The software factory described herein is a uniquely engineered scalableefficiency model construct that transforms a traditional softwaredevelopment art form into a repeatable scientific managed engineeredstreamline information supply chain. The software factory incorporatesapplied system and industrial engineering quality assured efficienciesthat provide for the waste eliminating, highly optimized performedinstrumentation, measured monitoring and risk mitigated management ofsoftware development.

Software Factory Overview

With reference now to the figures, and in particular to FIG. 1, anoverview of a preferred embodiment of a software factory 100 ispresented. As depicted, the software factory 100 is a service thatinteracts with both enterprise customers (i.e., client customers) 102 aswell as enterprise partners (i.e., third party vendors) 104. The primaryhuman interface with the enterprise customers 102 is through a ClientBusiness Governance Board (CBGB) 106. CBGB 106 represents clientstakeholders and client business sponsors that fund a project of thesoftware factory 100. CBGB 106 can be an internal or external client.That is, the same enterprise (i.e., internal client) may include bothCBGB 106 and software factory 100, or a first enterprise (i.e., externalclient) may have CBGB 106 while a second enterprise has the softwarefactory 100. As described in greater detail below, a project proposaldefinition is then run through a software factory induction process in aSoftware Factory Governance Board (SFGB) 108 and Software FactoryOperations (SFO) 110, where the project proposal definition isevaluated, qualified, scored and categorized. The project proposaldefinition is then subject to a System Engineering ConceptualRequirements Review by the SFGB 108. Based on the outcome of the reviewby the SFGB 108, a decision is made to accept the project proposaldefinition or to send it back to the CBGB 106 for remediation andresubmission through the Software Factory Induction Process.

Thus, Software Factory Governance, which includes SFGB 108 and SFO 110,provides the guidance, constraints, and underlying enforcement of allthe factory policies and procedures, in support of their governingprinciples in support of the strategic objects of the Software Factory100. Software Factory governance consists of factory business, IT andoperations governance. The principles, policies and procedures of thesemodels are carried out by two governing bodies—the Business GovernanceBoard and the IT Governance Board (both part of SFGB 108), and anenforcement body—the Software Factory Operations 110.

Thus, Software Factory Governance is responsible for:

Business and IT strategic planning;

Assuring that Business and IT strategies are aligned;

Setting Goals;

Monitoring those goals;

Detecting problems in achieving those goals;

Analyzing Problems;

Identifying Reasons;

Taking Action;

Providing Feedback; and

Re-Strategizing (Continue process improvement).

As soon as a project is deemed worthy to proceed, the job of creatingthe custom software is sent to a Design Center 112, where the project isbroken into major functional areas, including those handled by aRequirements Analysis Team 114 and an Architectural Team 116.

The Requirements Analysis Team 114 handles the Requirement Managementside of the Design Center 112, and is responsible for collecting thebusiness requirements from the lines of business and populating theserequirements into the tools. Analysis of business requirements is alsocarried out in order to derive associated IT requirements. Somerequirements (e.g. system requirements) may have a contractualconstraint to use a certain infrastructure. Requirements are analyzedand used in the basis for business modeling. These requirements andrepresentative business (contextual, event and process models) are thenverified with and signed off from project stakeholders. Requirements arethen base-lined and managed within release and version control.

The Architectural Side of the Design Center 112 is handled by theArchitecture Team 116, which takes the output of therequirement/analysis/management side of the design center, and usesarchitectural decision factors (functional requirements, non-functionalrequirements, available technology, and constraints), to model a designwith appropriate example representation into detail designspecification, that is bundled with other pertinent factors into a workpacket for assembly lines to execute.

Work Packets 118 are reusable, self-contained, discrete units ofsoftware code that constitute a contractual agreement that governs therelationship among Design Center 112, Software Factory Governance Board108, Software Factory Operations 110, and Assembly Line 120. That is,each work packet 118 includes governance policies and procedures (e.g.,including instructions for how work reports are generated andcommunicated to the client), standards (e.g., protocol for the workpacket 118), reused assets (e.g., reusable blocks of code, including therequirements, instructions and/or links/pointers associated with thosereusable blocks of code), work packet instructions (e.g., instructionsfor executing the work packet 118), integration strategy (e.g., how tointegrate the work packet 118 into a client's security system), schedule(e.g., when deliverables are delivered to the client), exit criteria(e.g., a checklist for returning the work packet 118 and/or deliverablesto the software factory 100), and Input/Output (I/O) work products(e.g., artifact checklist templates for I/O routines).

Assembly Line(s) 120 which are part of a Job Shop, include, but are notlimited to any team that is initialized, skilled and certified to acceptapplication factory work packets from the factory Design Center 112. JobShops receive and execute the work packets 118, which are specified bythe Design Center 112, to create a customized deliverable 122. As shownin exemplary manner, the assembly line 120 puts the work packets 118into a selected low-level design to generate a deliverable (executableproduct). While assembly line 120 can be a manual operation in which acoding person assembles and tests work packets, in another embodimentthis process is automated using software that recognizes project types,and automatically assembles work packets needed for a recognized projecttype.

Various tests can be performed in the assembly line 120, includingcode/unit tests, integration test, system test, system integration test,and performance test. “Code/unit test” tests the deliverable forstand-alone bugs. “Integration test” tests the deliverable forcompatibility with the client's system. “System test” checks theclient's system to ensure that it is operating properly. “Systemintegration test” tests for bugs that may arise when the deliverable isintegrated into the client's system. “Performance test” tests thedeliverable as it is executing in the client's system. Note that if thedeliverable is being executed on a service provider's system, then alltests described are obviously performed on the service provider's systemrather than the client's system.

A User Acceptance Test Team 124 includes a client stakeholder that ischarged with the responsibility of approving acceptance of deliverable122.

Software factory 100 may utilize enterprise partners 104 to providehuman, hardware or software support in the generation, delivery and/orsupport of deliverables 122. Such third party contractors are viewed asa resource extension of the software factory 100, and are governed underthe same guidelines described above.

If an enterprise partner 104 is involved in the generation of workpackets 118 and/or deliverables 122, an interface between the softwarefactory 100 and the enterprise partner 104 may be provided by a serviceprovider's interface team 126 and/or a product vendor's interface team128. Service provided by an enterprise partner 104 may be a constraintthat is part of contractual agreement with a client to providespecialized services. An example of such a constraint is a requiredintegrated information service component that is referenced in theintegration design portion of the work packet 118 that is sent toassembly line 120. Again, note that third party service providers use astandard integration strategy that is defined by the software factory100, and, as such, are subject to and obligated to operate undersoftware factory governance.

Product vendor's interface team 128 provides an interface with a ProductVendor, which is an enterprise partner 104 that provides softwarefactory 100 with supported products that maybe used within a softwarefactory solution. Product Vendors are also responsible for providingproduct support and maintaining vendor's relationships, which aremanaged under the software factory's governance guidelines.

Support Team 130 includes both Level 2 (L2) support and Level 1 (L1)support.

L2 Support is provided primarily by Software Engineers, who provideproblem support of Software Factory produced delivered code forcustomers. That is, if a deliverable 122 doesn't run as designed, thenthe software engineers will troubleshoot the problem until it is fixed.These software engineers deliver technical assistance to SoftwareFactory customers with information, tools, and fixes to prevent knownsoftware (and possibly hardware) problems, and provide timely responsesto customer inquiries and resolutions to customer problems.

L1 support is primarily provided by an L1 Help Desk (Call Center). L1Help Desk support can be done via self-service voice recognition andvoice response, or by text chat to an automated smart attendant, or acall can be directed to a Customer Service Representative (CSR).Customer Service Representatives in this role provide first line of helpproblem support of Software Factory produced deliverables. Such helpincludes user instruction of known factory solution procedures. For anyrelated customers issues that cannot be resolved through L1, the L1 HelpDesk will provide preliminary problem identification and create troubleticket entry into trouble tracking system, which then triggers aworkflow event to dynamically route the problem issue to an availableand appropriate L2 support group queue.

With reference now to FIG. 2, a flow-chart of exemplary steps taken tocreate custom software through the use of a software factory ispresented. After initiator block 202, which may be a creation of acontract between an enterprise client and a software factory service,input, from a Client Business Governance Board, is received at asoftware factory (block 204). This input is a detailed description ofthe custom software needs of the enterprise client. While such input isusually prepared and presented by human management of the enterpriseclient, alternatively this input may be the creation of a UnifiedModeling Language (UML) based description of the needed software. Basedon the client's input, a project software proposal definition is createdby the Software Factory Governance Board of the software factory (block206). This project software proposal definition is sent to thescheduling/dispatching department of the Software Factory Operations,which creates a software project.

The software project is then inducted (block 208). As will be describedin more detail below, the project induction provides an initialintroduction of the project to the software factory. Through the use ofvarious parameters, including those found in records of other projects,checklists, et al., the project is initially evaluated. This evaluationincludes determining if the software factory has the capacity,resources, bandwidth, etc. needed for the project. If so, then adetermination is made as to whether the project is qualified foracceptance by the software factory. Such qualification includes, but isnot limited to, determining if the project falls within the guidelinesset by a Service Level Agreement (SLA) between the client enterprise andthe software factory, whether the project conforms to legal guidelinessuch as Sarbanes-Oxley, etc. Based on these and other criteria, theproject is scored for feasibility, profitability, and desirability forimplementation. If the induction process concludes that the projectshould proceed, then it is categorized into a particular type of project(e.g., payroll, inventory control, database management, marketing, etal.).

If the induction process does not pass (query block 210), indicatingthat the project should not proceed, then the project is returned to theClient Business Governance Board for additional discussions between theClient Business Governance Board and the software factory, in order toinduct a revised project (i.e., reinduct the software project). However,if the induction process passes, then the software project is parsedinto major functional areas (block 212). That is, the project is dividedup (“broken apart”) in order to establish subunits that can later beintegrated into a single custom software (“deliverable”).

Work packets are then obtained for all of the functional areas of thesoftware project (block 214). These work packets are reusable componentswhich are described in detail below. The work packets are then stitchedtogether (block 216) on an assembly line to create deliverable customsoftware that meets the criteria for the software project that has beenestablished in the earlier steps. The custom software is then tested inthe software factory (block 218). Once testing is completed, the customsoftware is delivered (block 220) to the client customer, who receiveson-going support from the support team (block 222). The flow-chart endsat terminator block 224.

While the process has been described for the creation of customsoftware, the same process is used by a software factory for otheractivities, including creating a service for a customer, creatingstandardized software, etc. Thus, the software factory uses work packetsto blend software (including reusable artifacts), protocols (e.g., howsoftware will be transmitted, how individuals will be contacted, etc.),governance requirements (e.g., service level agreements that describehow much a service will cost) and operating environments (hardware andsoftware, including operating systems, integrated environments such asSAP™, Rational™, etc.) into a single integrated product, which can thenbe used in a stand-alone manner or can be fed into anothersystem/product.

Note that software factory 100 is virtual. That is, the differentcomponents (e.g., software factory governance board 108, softwarefactory operations 110, design center 112, assembly line 120) may belocated in different locations, and may operate independently under thecontrol of information found in work packets 118. In a preferredembodiment, each of the different components of the software factory 100publishes a set of services that the component can provide and a set ofrequirements for using these services. These services are functions thatare well defined and made visible for outside entities to call.

For example, assume that assembly line 120 publishes a service that itcan assemble only work packets that include code and protocol thatutilize IBM's Rational™ software development platform. Thus, theassembly line 120 has published its service (set of services includes“assembling work packets”) and the required protocol (set ofrequirements includes “utilize IBM's Rational™ software developmentplatform”) to the design center 112, which must decide if it wants (oris able) to utilize that particular assembly line 120. If not, thenanother assembly line from another software factory may be called uponby the design center 112. Behind each offered service are the actualprocesses that a component performs. These processes are steps taken bythe service. Each step is performed by a section of software, or may beperformed by an individual who has been assigned the task of performingthis step. Each step utilizes leveraged tools, including the workpackets 118 described herein. These work packets 118 then implement theprocess.

By utilizing published interfaces between the different components ofthe software factory 100, then different components from differentsoftware factories can be interchanged according to the capabilityoffered by and protocol used by each component. This enables a “buildingblock” architecture to be implemented through the use of differentcomponents from different software factories.

Life Cycle of a Work Packet

There are five phases in the life cycle of a work packet, which areshown in FIG. 3. These five phases are 1) Defining (block 302); 2)Assembling (block 304); Archiving (block 306); Distributing (block 308);and Pulling for Execution (block 310). As indicated by the top dashedline coming out of asset repository 312, this life cycle may berecursive. That is, in one embodiment, work packets are modified andupgraded in a recursive manner, which includes the steps shown in FIG.3. Once a work packet is assembled and archived, it is stored in anasset repository 312, whence the work packet may be accessed andutilized by an asset manager 314 for assembly into a deliverable by anassembly line 316. Note that the assembly line 316 can also send, to theasset manager 314, a message 318 that requests a particular work packet320, which can be pulled (block 310) into the asset repository 312 bythe asset manager 314. This pulling step (block 310), is performedthrough intelligent routing distribution (block 308) to the assetrepository 312 and assembly line 316. The configuration of the routingdistribution of the work packet 320 is managed by the asset manager 314,which is software that indexes, stores and retrieves assets created andused with the software factory.

Work Packet Components

A work packet is a self-contained work unit that comprises processes,roles, activities (parts of the job), applications, and necessary inputparameters that allow a team to conduct a development activity in aformalized manner, with visibility to progress of their effort affordedto requesting teams. A work packet is NOT a deliverable softwareproduct, but rather is a component of a deliverable software product.That is, a work packet is processed (integrated into a system, tested,etc.) to create one or more deliverables. Deliverables, which werecreated from one or more work packets, are then combined into a customsoftware, such as an application, service or system.

In a preferred embodiment, a work packet is composed of the followingeight components:

Governance Policies and Procedures

these policies and procedures include protocol definitions derived froma project plan. That is, a project plan for a particular custom softwaredescribes how work packets are called, as well as how work packetsreport back to the calling plan.

Standards

this component describes details about how work packets are implementedinto a deliverable in a standardized manner. Examples of such standardsare naming conventions, formatting protocol, etc.

Reused Assets

this component includes actual code, or at least pointers to code, thatis archived for reuse by different assembled deliverables.

Work Packet Instructions

this component describes detailed instructions regarding how a workpacket is actually executed. That is, work packet instructions documentwhat work packets need to be built, and how to build them. Theseinstructions include a description of the requirements that need to bemet, including design protocols, code formats, and test parameters.

Integration Strategy

this component describes how a set of work packets, as well asdeliverables developed from a set of work packets, are able to beintegrated into a client's system. This component includes instructionsregarding what processes must be taken by the client's system to beprepared to run the deliverable, as well as security protocols that mustbe followed by the deliverable. The component may also include adescription of how one deliverable will interact with other applicationsthat are resident to the client's computer system.

Scheduling

this component describes when a set of work packets are to be sent to anassembly line, plus instructions on monitoring the progress and statusof the creation of the work packet.

Exit Criteria

this component includes instructions (e.g., through the use of achecklist) for deploying a deliverable to the client's system. That is,this component is the quality criteria that the deliverable must meetbefore it can be considered completed and acceptable for a project.

Input Work Products

this component includes Input/Output (I/O) templates that are used todescribe specific work products that are needed to execute theactivities of the work packet (in the assembly line) to build thedeliverable.

Defining a Work Packet

The process of defining a work packet is called a “work packetdefinition process.” This process combines critical references fromgovernance, factory operations (e.g., factory management, projectmanagement), business criteria, and design (including test) artifacts.Structured templates enable governance, design center, and factoryoperations to define the referenced artifacts by filling incorresponding functional domain templates, thus defining the contents ofthe work packet. Thus, a work packet includes not only reusable softwarecode, but also includes governance and operation instructions. Forexample, a work packet may include directions that describe a sequenceof steps to be taken in a project; which data is to be used in theproject; which individuals/departments/job descriptions are to performeach step in the project; how assigned individuals/departments are to benotified of their duties and what steps/data are to be taken and used,et al. Thus, each work packet includes traceability regarding the statusof a job, as well as code/data/individuals to be used in the executionof a project.

Thus, work packets are created from unique references to governance,factory operations (factory mgt, project mgt), business, and design(including test) artifacts. The packet definition process providesstructure templates that enable governance, design center, and factoryoperations to define referenced artifacts (newly defined artifactidentifiers or any reusable part of existing work packet definitions),by filling in corresponding functional domain (e.g., eXtensible MarkupLanguage—XML) templates. What can be defined may be controlled by aDocument Type Definition (DTD). The DTD states what tags and attributesare used to describe content in the deliverable, including where eachXML tag is allowed and which XML tags can appear within the deliverable.XML tag values are defined and applied to a newly defined XML templatefor each functional area of a design center. These XML templates arethen merged into one hierarchical structure when later assembled intofinalized work packets.

With reference now to FIG. 4, an overview of the environment in which apacket definition process 402 occurs is presented. The packet definitionprocess 402 calls artifacts 404, metrics 406, and a template 408 todefine a work packet. The artifacts may be one or more of: governanceartifacts 410 (intellectual property assets produced in the softwarefactory by the Software Factory Governance Board 108 described in FIG.1); business contextual artifacts 412 (intellectual property assetsproduced in the software factory by business analysts in the requirementanalysis team 114 described in FIG. 1); architectural artifacts 414(intellectual property assets produced by the architecture team 116described in FIG. 1); test artifacts 416 (intellectual property assetsproduced by test architects in the architecture team 116 shown in FIG.1); and project artifacts 418 (intellectual property assets produced inthe software factory by system engineers in the design center 112 shownin FIG. 1).

The metrics 406 may be one or more of: governance metrics 420(measurable governance indicators, such as business plans); factorymetrics 422 (measurable indicators that describe the capabilities of thesoftware factory, including assembly line capacity); and system metrics424 (measurable indicators that describe the capabilities of theclient's computer system on which deliverables are to be run).

Based on a template 408 for a particular deliverable, artifacts 404 andmetrics 406 are used by a packet assembly process 426 to assemble one ormore work packets.

Assembling a Work Packet

Template 408, shown in FIG. 4, describes how a work packet is to beassembled. The template 408 includes metadata references to keyartifacts 404 and metrics 406, which are merged into a formal workpacket definition as described above. The work packet is then assembledin a standardized hierarchical way and packaged within a factory messageenvelope that contains a header and body.

With reference now to FIG. 5, a high-level flow-chart of steps taken todefine and assemble work packets is presented. After initiator block 502(which may be an order by the Requirements Analysis Team 114 to theArchitecture Team 116, shown in FIG. 1, to create a designcenter-defined work packet), the requisite packet definitions arecreated for work packets that are to be used in deliverables (block504). First, a template, which preferably is a reusable that has beenused in the past to create the type of work packet needed, is called(block 506). Based on that called template, the needed artifacts (block508) and metrics (block 510) are called. Using the template as a guide,the called artifacts and metrics are assembled in the requisite workpackets (block 512), and the process ends.

With reference now to the figures, and in particular to FIG. 6, there isdepicted a block diagram of an exemplary computer 602, which may beutilized by the present disclosure. Computer 602 includes a processorunit 604 that is coupled to a system bus 606. Processor unit 604 mayutilize one or more processors, each of which has one or more processorcores. A video adapter 608, which drives/supports a display 610, is alsocoupled to system bus 606. System bus 606 is coupled via a bus bridge612 to an input/output (I/O) bus 614. An I/O interface 616 is coupled toI/O bus 614. I/O interface 616 affords communication with various I/Odevices, including a keyboard 618, a mouse 620, a media tray 622 (whichmay include storage devices such as CD-ROM drives, multi-mediainterfaces, etc.), a floppy disk drive 624, and flash drive memory 626.While the format of the ports connected to I/O interface 616 may be anyknown to those skilled in the art of computer architecture, in apreferred embodiment some or all of these ports are universal serial bus(USB) ports. Note that some or all of the architecture depicted forcomputer 602 may be utilized by software deploying computer 650,resource requesting computer 652, and/or resource availability computer654.

As depicted, in one embodiment, computer 602 is optionally able tocommunicate via network 628 using a network interface 630. Network 628may be an external network such as the Internet, or an internal networksuch as an Ethernet or a virtual private network (VPN).

A hard drive interface 632 is also coupled to system bus 606. Hard driveinterface 632 interfaces with a hard drive 634. In a preferredembodiment, hard drive 634 populates a system memory 636, which is alsocoupled to system bus 606. System memory is defined as a lowest level ofvolatile memory in computer 602. This volatile memory includesadditional higher levels of volatile memory (not shown), including, butnot limited to, cache memory, registers and buffers. Data that populatessystem memory 636 includes computer 602's operating system (OS) 638 andapplication programs 644.

OS 638 includes a shell 640, for providing transparent user access toresources such as application programs 644. Generally, shell 640 is aprogram that provides an interpreter and an interface between the userand the operating system. More specifically, shell 640 executes commandsthat are entered into a command line user interface or from a file.Thus, shell 640, also called a command processor, is generally thehighest level of the operating system software hierarchy and serves as acommand interpreter. The shell provides a system prompt, interpretscommands entered by keyboard, mouse, or other user input media, andsends the interpreted command(s) to the appropriate lower levels of theoperating system (e.g., a kernel 642) for processing. Note that whileshell 640 is a text-based, line-oriented user interface, the presentdisclosure will equally well support other user interface modes, such asgraphical, voice, gestural, etc.

As depicted, OS 638 also includes kernel 642, which includes lowerlevels of functionality for OS 638, including providing essentialservices required by other parts of OS 638 and application programs 644,including memory management, process and task management, diskmanagement, and mouse and keyboard management.

Application programs 644 include a renderer, shown in exemplary manneras a browser 646. Browser 646 includes program modules and instructionsenabling a world wide web (WWW) client (i.e., computer 602) to send andreceive network messages to the Internet using hypertext transferprotocol (HTTP) messaging, thus enabling communication with softwaredeploying server 650 and other described computer systems.

Application programs 644 also include a resource allocation program(RAP) 648, which, when executed, performs some or all of the processesdescribed in FIGS. 1-5 and 7-8. In one embodiment, RAP 648 isdownloadable from software deploying server 650 in an on-demand basis,such that units of code are downloaded only when needed. In anotherembodiment, some or all of the processes executed by RAP 648 areperformed by software deploying server 650 itself, thus minimizing theuse of resources within computer 602.

Resource requesting computer 652 may be affiliated with one or moreparticular work areas within an enterprise or a project. Similarly,resource availability computer 652 may be affiliated with one or moreparticular work areas within an enterprise or a project. Utilizing themethodology described herein, resources can be reallocated from an areaassociated with resource availability computer 652 to another areaassociated with resource requesting computer 652, while contemplatingramp-up indexes, affinity indexes, priorities, etc. described herein.

The hardware elements depicted in computer 602 are not intended to beexhaustive, but rather are representative to highlight essentialcomponents required by the present disclosure. For instance, computer602 may include alternate memory storage devices such as magneticcassettes, digital versatile disks (DVDs), Bernoulli cartridges, and thelike. These and other variations are intended to be within the spiritand scope of the present disclosure.

Referring now to FIG. 7, a relationship among a resource allocatingsystem 702, multiple functional areas 706 a-n (where “n” is an integer),and multiple resources 710 a-m (where “m” is an integer) is presented.In one embodiment, resource allocating system 702 can be some or all ofcomputer 602 shown in FIG. 6. Functional areas 706 a-n can communicatewith resource allocating system 702 via a resource requesting computer,such as resource requesting computer 652 shown in FIG. 6. The existenceof resources 710 a-m, or even the resources 710 a-m themselves, can bemade known by a resource computer such as resource availability computer654 shown in FIG. 6. As depicted, resource allocating system 702utilizes allocation logic 708 (e.g., RAP 648 shown in FIG. 6) to receiverequests 704 for resources from functional areas 706 a-n. In a mannerdescribed herein, these requests 704 may ultimately result in resourceallocations 712, which allocations are also under the control anddirection of allocation logic 708.

The present disclosure describes various embodiments of constructing theobjective function and constraints that allow for simultaneousmaintenance of the resources and application services at the currenttime and their development in future, including those resources andservices needed by the software factory described above. Some of theconsiderations that are taken into account for resource allocation are:(a) as the demand profile for resources changes, there is a need to movethe resources between functional areas or assembly centers to optimizeresource utilization (minimize bench time); (b) rotate resourcespro-actively to build up certain skill profiles of resources based onpredicted future need; (c) functional area skills may be “sticky” i.e.,specific functional areas have a ramp up period during which the abilityof the people improves as they specialize in that functional area; and(d) highly productive resources may need to be treated differently sincerotating such resources may have a heavy impact on overall productivityof other resources in the functional area. Thus, described herein is amethod and system to balance the benefits of dynamic resource allocationagainst the benefits of resource specialization in certain functionalareas. Depending on the expected variability in demand for resourceskills, skill specific ramp-up time, current resource utilization levelsby skill type, resource productivity level and expected resourceturnover time (i.e., mean service length of a newly onboarded resource),the methodology described herein chooses an appropriate strategy forresource allocation.

In one embodiment of the present disclosure, Equation (1) shown above isreformulated to allow different treatment of expert/productiveresources. This reformulation is represented below as Equation (2):

$\begin{matrix}{{x(t)}^{*} = {\underset{\underset{{{V{({x_{k}{(t)}})}}{P{({{x_{k}{(t)}} \neq {x_{k}{({t - 1})}}})}}} = {p_{k}{(t)}}}{{c_{i}{({x{(t_{j})}})}} \geq 0}}{argmin}{f\left( {{x\left( {t - 1} \right)},{\ldots \mspace{14mu} {x(0)}}} \right)}}} & {{Equation}\mspace{14mu} (2)}\end{matrix}$

In Equation (2), V(x_(k)(t)) represents the value of resource k at timet (which is by definition between 1 and infinity). In one embodiment ofthe present disclosure, this value is a function of productivity andskill set, among other things. Operator P( ) stands for probability.Finally p_(k)(t) is the calculated dynamic probability of a movement forresource k at time t. The newly added constraintV(x_(k)(t))P(x_(k)(t)≠x_(k)(t−1))=p_(k)(t) states that as the value of aresource increases, the probability of any movement and re-allocationfor that resource decreases. Conversely, for resources with relativelylow value, the probability of movement would be equal to the dynamicprobability of movement at that time.

Another embodiment of the present disclosure is realized byreformulating Equation (1) to add a value for resource development. Thisreformation is represented in Equation (3):

$\begin{matrix}{{x(t)}^{*} = {{\underset{{c_{i}{({x{(t_{j})}})}} \geq 0}{argmin}{f\left( {{x\left( {t - 1} \right)},{\ldots \mspace{14mu} {x(0)}}} \right)}} + {c\left\lbrack {{s\left( {x_{k}(t)} \right)} - {s\left( {x_{k}\left( {t - 1} \right)} \right)}} \right\rbrack}}} & {{Equation}\mspace{14mu} (3)}\end{matrix}$

where s(x_(k)(t)) is the overall skill (a measure of development) ofresource k at time t, and c is an appropriate weighting factor that maybe a function of time among other things. In other words, Equation (3)allows a sub-optimal paining to happen in order to promote thedevelopment of resources for future profit.

With reference now to FIG. 8, a high level flow chart of steps taken toallocate and/or reallocate resources to functional areas of anenterprise activity environment is presented. After initiator block 802,a determination is made of a skill level of a resource in multiplefunctional areas (block 804). This resource may be a computer, a storagedevice, a service (e.g., a service in a service orientedarchitecture—SOA), etc. However, in the embodiment described inexemplary manner herein, this resource is a person who has a specificskill level in each of the multiple functional areas. For example, theperson may work on an assembly line in a software factory (described indetail above). Thus, the person has measurable skill levels in one ormore of the positions on that assembly line. This skill level may bedetermined by and based on past performance by that person on previousprojects. In addition (or alternatively), this skill level may be basedon test results of tests administered to the person. Similarly, suchprior evaluations/performance reviews/tests may be administered to anyresource, including hardware, software, etc.

As depicted in block 806, a unique ramp-up index is created andassociated with each of the multiple functional areas. Each uniqueramp-up index is based on a rate of growth of the skill level for theresource as a function of time spent to develop a requisite skill levelof the resource within each functional area. For example, assume againthat the resource is a person. The ramp-up index is a measurement of howlong it will take existing and/or new workers within a functional area(e.g., an assembly line) to raise their collective current skill levelsup to a requisite skill level that has been predetermined according to aservice level agreement with a customer, baseline tests, expectedproductivity based on past productivity within that functional area orone similar, etc.

As depicted in block 808, an affinity index is created and associatedwith each of the multiple functional areas. This affinity index is basedon a level of productivity drop of other resources in a specificfunctional area if the resource is assigned to another functional area.For example, assume that the resource is an experienced worker who isknown to not only be highly productive, but is also an excellentresource for other workers to approach with their own technicalquestions. If this experienced worker/mentor is removed from a firstfunctional area to another functional area, then the productivity of theworkers left behind in the first functional area will decline.

As described in block 810, expected resource and skill levelrequirements for a project are identified. For example, assume that theproject is to deliver a new software package. The customer may havecertain expectations regarding what level of expertise is held byworkers on the project (skill level requirements) as well as how manypersons will be assigned to the project (resource requirements).

As described in block 812, a cohesion index for each team is defined. Acohesion index is similar to an affinity index, except that the cohesionindex is based solely on personnel disruption, whether that disruptionis caused by adding or removing a team member. That is, the affinityindex describes how disruptive it will be to a team to remove a key teammember. However, adding a team member, even a worker who is highlyskilled, may be just as disruptive to a team. This disruption can be dueto a variety of factors, including interpersonal issues, a time zonedifference for the new team member, logistical issues (i.e., findingworkspace, resources, computing time, etc. for the new team member),etc. Thus, if a team is highly performing, then they should not bedisrupted by adding a new team member, and will have a high cohesionindex. However, if a team is performing poorly, then that team'scohesion index will be low.

As shown in block 814, based on these expected resource and skill levelrequirements, resources are automatically allocated to one or more ofthe functional areas based on the ramp-up index and the affinity indexthat were created and associated/assigned to the various functionalareas as described in block 806-808, as further explained in exemplarymanner in Equations (2)-(3) above, as well as the cohesion indexdescribed in block 812.

As stated further in block 814, in one embodiment the resources areallocated/reallocated by determining a predicted breakpoint forreassigning an existing resource. This predicted breakpoint defines apoint in time at which lost productivity caused by removing the existingresource from a first functional area is equally offset by increasedproductivity in a second functional area to which the existing resourceis now assigned. Thus, assume that removing a worker from a first arearesults in some measureable reduction in productivity (e.g., a reducedamount of software code being written) in the first area. Thetransferred worker will cause an increase in productivity in the secondarea to which she has been transferred. However, there will be aramping-up period for that transferred worker, during which time herproductivity will increase. At some point, the level of decreasedproduction in the first area will be equal to, or preferably surpassedby, an increased level of production in the second area to which she wastransferred. How long it takes to reach this breakpoint can be comparedto a predicted/acceptable breakpoint, which may be dependent on thelength of the project on which the worker is working. Thus, if theproject is five years long, then a breakpoint date of six months may beacceptable, assuming that transferring the worker will result inlong-term gain in her productivity. However if the project is only threemonths long but the breakpoint date is still six months after thetransfer, then there will be a net loss in overall productivity, andthus the transfer will not take place.

As stated further in block 814, in one embodiment the resources areallocated/reallocated by the processor assigning a short term priorityweight to short term needs of a particular functional area and a longterm priority weight to long term needs of the particular functionalarea. The short term priority weight describes a first priority levelfor short term activities in the particular functional area. The longterm priority weight describes a second priority level for long termactivities in the particular functional area. For example, assume thattransferring an resource from a first area to a second area will resultin the first area having reduced productivity due to that transfer,while the second area will have increased productivity. If long-termactivities of the second area have been deemed to be more important thanshort-term activities of the first area, then the worker will betransferred to the second area. However, if short-term activities of thefirst area have been deemed to be more important than long-termactivities of the second area, then the worker will be not betransferred, and will remain in the first area (or another area having ahigher priority weight). These priority weights can be based on one ormore factors. In one embodiment, a factor considered in the creation ofa priority weight for an area is based on whether or not that area is“mission critical”. Thus, certain areas produce portions/aspects of thetotal job that are essential to the success/functionality of theproject. Such critical areas may be assigned to produce core lines ofcode for a software project (e.g., code that handles the main and/orunique aspect of the project); to provide critical hardware components(e.g., processing power and/or memory capacity), etc. Other areas,however, may be deemed less important, such as areas that createsoftware code for add-on functionalities that are not critical to theproject, hardware such as input/output devices that are not immediatelyneeded to deploy the project, etc. Thus, based on which area has ahigher priority weight, the resource/worker will be assignedaccordingly. In one embodiment, this priority weight, including thehigher priority weight, is based on a ramp-up index and an affinityindex. That is, the priority weight is based in part on the ramp-upindex and/or affinity index described above. For example, assume that acertain area is initially deemed to have a low priority weight. However,if that certain area has a high ramp-up index and/or a high affinityindex, then its priority weight is raised accordingly, thus making itless vulnerable to worker raids from other areas.

The process ends at terminator block 816.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of various embodiments of the present invention has beenpresented for purposes of illustration and description, but is notintended to be exhaustive or limited to the invention in the formdisclosed. Many modifications and variations will be apparent to thoseof ordinary skill in the art without departing from the scope and spiritof the invention. The embodiment was chosen and described in order tobest explain the principles of the invention and the practicalapplication, and to enable others of ordinary skill in the art tounderstand the invention for various embodiments with variousmodifications as are suited to the particular use contemplated.

Note further that any methods described in the present disclosure may beimplemented through the use of a VHDL (VHSIC Hardware DescriptionLanguage) program and a VHDL chip. VHDL is an exemplary design-entrylanguage for Field Programmable Gate Arrays (FPGAs), ApplicationSpecific Integrated Circuits (ASICs), and other similar electronicdevices. Thus, any software-implemented method described herein may beemulated by a hardware-based VHDL program, which is then applied to aVHDL chip, such as a FPGA.

Having thus described embodiments of the invention of the presentapplication in detail and by reference to illustrative embodimentsthereof, it will be apparent that modifications and variations arepossible without departing from the scope of the invention defined inthe appended claims.

What is claimed is:
 1. A method for automated allocation of resources tofunctional areas of an enterprise activity environment, the methodcomprising: determining, by one or more processors, a skill level of aresource in multiple functional areas, wherein the resource has aspecific skill level in each of the multiple functional areas; creatingand associating, by one or more processors, an affinity index with eachof the multiple functional areas, wherein the affinity index is based ona level of productivity drop of other resources in a specific functionalarea if the resource is assigned to another functional area;identifying, by one or more processors, expected resource and skilllevel requirements of a project; and automatically allocating, by one ormore processors, the resource to one or more functional areas based onthe affinity index associated with a particular functional area in viewof the expected resource and skill level requirements.
 2. The method ofclaim 1, wherein the enterprise activity environment is a softwarefactory, and wherein said each functional area is a work station withinthe software factory.
 3. The method of claim 1, further comprising:determining, by one or more processors, a predicted breakpoint forreassigning an existing resource, wherein the predicted breakpointdefines a point in time at which lost productivity caused by removingthe existing resource from a first functional area is equally offset byincreased productivity in a second functional area to which the existingresource is now assigned; determining, by one or more processors, anacceptable breakpoint based on a length of the project; and reassigning,by one or more processors, the existing resource from the firstfunctional area to the second functional area only if the predictedbreakpoint does not exceed the acceptable breakpoint.
 4. The method ofclaim 1, further comprising: assigning, by one or more processors, ashort term priority weight to short term needs of a particularfunctional area and a long term priority weight to long term needs ofthe particular functional area, wherein the short term priority weightdescribes a first priority level for short term activities in theparticular functional area, and wherein the long term priority weightdescribes a second priority level for long term activities in theparticular functional area; determining, by one or more processors, ahigher priority weight by comparing the short term priority weight tothe long term priority weight; and reallocating, by one or moreprocessors, resources based on the higher priority weight.
 5. The methodof claim 4, wherein the higher priority weight is based on a cohesionindex and the affinity index, wherein the cohesion index describes howsensitive a productivity of a team is to worker reassignments.
 6. Themethod of claim 1, wherein the skill level of the resource is based onpast performance by the resource on previous projects.
 7. The method ofclaim 1, wherein the skill level of the resource is based on testresults of tests administered to the resource.
 8. The method of claim 1,wherein the resource is a person.
 9. The method of claim 8, wherein theskill level of the resource is based on a self-assessed skill level ofthe person.
 10. The method of claim 8, wherein the skill level of theresource is based on a peer-assessed skill level of the person.
 11. Acomputer program product for automated allocation of resources tofunctional areas of an enterprise activity environment, the computerprogram product comprising: a computer readable storage media; firstprogram instructions to determine a skill level of a resource inmultiple functional areas, wherein the resource has a specific skilllevel in each of the multiple functional areas; second programinstructions to associate an affinity index with each of the multiplefunctional areas, wherein the affinity index is based on a level ofproductivity drop of other resources in a specific functional area ifthe resource is assigned to another functional area; third programinstructions to identify expected resource and skill level requirementsof a project; and fourth program instructions to automatically allocatethe resource to one or more functional areas based on the affinity indexassociated with a particular functional area in view of the expectedresource and skill level requirements; and wherein the first, second,third, and fourth program instructions are stored on the computerreadable storage media.
 12. The computer program product of claim 11,wherein the enterprise activity environment is a software factory, andwherein said each functional area is a work station within the softwarefactory.
 13. The computer program product of claim 11, furthercomprising: fifth program instructions to determine a predictedbreakpoint for reassigning an existing resource, wherein the predictedbreakpoint defines a point in time at which lost productivity caused byremoving the existing resource from a first functional area is equallyoffset by increased productivity in a second functional area to whichthe existing resource is now assigned; sixth program instructions todetermine an acceptable breakpoint based on a length of the project; andseventh program instructions to reassign the existing resource from thefirst functional area to the second functional area only if thepredicted breakpoint does not exceed the acceptable breakpoint; andwherein the fifth, sixth, and seventh program instructions are stored onthe computer readable storage media.
 14. The computer program product ofclaim 11, further comprising: fifth program instructions to assign ashort term priority weight to short term needs of a particularfunctional area and a long term priority weight to long term needs ofthe particular functional area, wherein the short term priority weightdescribes a first priority level for short term activities in theparticular functional area, and wherein the long term priority weightdescribes a second priority level for long term activities in theparticular functional area; sixth program instructions to determine ahigher priority weight by comparing the short term priority weight tothe long term priority weight; and seventh program instructions toreallocate resources based on the higher priority weight; and whereinthe fifth, sixth, and seventh program instructions are stored on thecomputer readable storage media.
 15. The computer program product ofclaim 14, wherein the higher priority weight is based on a cohesionindex and the affinity index, wherein the cohesion index describes howsensitive a productivity of a team is to worker reassignments.
 16. Acomputer system comprising: a central processing unit (CPU), a computerreadable memory, and a computer readable storage media; first programinstructions to determine a skill level of a resource in multiplefunctional areas, wherein the resource has a specific skill level ineach of the multiple functional areas; second program instructions toassociate an affinity index with each of the multiple functional areas,wherein the affinity index is based on a level of productivity drop ofother resources in a specific functional area if the resource isassigned to another functional area; third program instructions toidentify expected resource and skill level requirements of a project;and fourth program instructions to automatically allocate the resourceto one or more functional areas based on the affinity index associatedwith a particular functional area in view of the expected resource andskill level requirements; and wherein the first, second, third, andfourth program instructions are stored on the computer readable storagemedia for execution by the CPU via the computer readable memory.
 17. Thecomputer system of claim 16, wherein the enterprise activity environmentis a software factory, and wherein said each functional area is a workstation within the software factory.
 18. The computer system of claim16, further comprising: fifth program instructions to determine apredicted breakpoint for reassigning an existing resource, wherein thepredicted breakpoint defines a point in time at which lost productivitycaused by removing the existing resource from a first functional area isequally offset by increased productivity in a second functional area towhich the existing resource is now assigned; sixth program instructionsto determine an acceptable breakpoint based on a length of the project;and seventh program instructions to reassign the existing resource fromthe first functional area to the second functional area only if thepredicted breakpoint does not exceed the acceptable breakpoint; andwherein the fifth, sixth, and seventh program instructions are stored onthe computer readable storage media for execution by the CPU via thecomputer readable memory.
 19. The computer system of claim 16, furthercomprising: fifth program instructions to assign a short term priorityweight to short term needs of a particular functional area and a longterm priority weight to long term needs of the particular functionalarea, wherein the short term priority weight describes a first prioritylevel for short term activities in the particular functional area, andwherein the long term priority weight describes a second priority levelfor long term activities in the particular functional area; sixthprogram instructions to determine a higher priority weight by comparingthe short term priority weight to the long term priority weight; andseventh program instructions to reallocate resources based on the higherpriority weight; and wherein the fifth, sixth, and seventh programinstructions are stored on the computer readable storage media forexecution by the CPU via the computer readable memory.
 20. The computersystem of claim 16, wherein the higher priority weight is based on acohesion index and the affinity index, wherein the cohesion indexdescribes how sensitive a productivity of a team is to workerreassignments.